home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / bbsutil / tick200.zip / TIC2NOTS.DOC < prev    next >
Text File  |  1990-02-19  |  16KB  |  349 lines
  1.  
  2.  
  3.  
  4.                                    Betatic.doc
  5.  
  6.                 Tick 1.31 -
  7.  
  8.                 * Fixed a minor bug that could allow an invalid  AKA  to  be
  9.            used in rare cases.
  10.  
  11.                 * First attempt at instituting the SECONDARY areas.   If you
  12.            ever followed the AREA name in the TIC.CFG file  with  something,
  13.            you  might  have  encountered  the  message about not finding the
  14.            secondary area.   That was a result of code that  was  only  par-
  15.            tially implemented.  Now to explain what a secondary area is, and
  16.            how it works:
  17.  
  18.                 AREA c:\dir\dir2\boo SOFTDIST R13DIST
  19.  
  20.                 The line above is the start of an area block that declares a
  21.            primary  area  tag  of  SOFTDIST,  and  a  secondary  area called
  22.            "R13DIST".  R13DIST MUST be defined as the primary tag of another
  23.            AREA block.
  24.  
  25.                 What will happen  is  this:    If  a  file  is  received  in
  26.            SOFTDIST,  the  file  will  be  echoed  to the nodes listed under
  27.            SOFTDIST (with a file-echo-tag of SOFTDIST),  and  to  the  nodes
  28.            listed  in  R13DIST  (with  a  file-echo-tag of R13DIST).   Files
  29.            received in R13DIST will NOT echo into SOFTDIST,  unless SOFTDIST
  30.            is also a secondary area for R13DIST.
  31.  
  32.                 Files  entering  your  node  will be tossed to the SECONDARY
  33.            area's toss-to directory if a secondary area is defined.  (It can
  34.            be the same as the primary area's directory.)  The  exception  to
  35.            this  is  if STOPDUP is active.   In that event,  if the file has
  36.            been seen in the secondary area but not in the primary  area,  it
  37.            will toss to the primary area.
  38.  
  39.                 If  STOPDUP  is active,  echo will be suppressed in any area
  40.            that has already seen the file.  If the file has been seen in the
  41.            primary, but not the secondary area, only the secondary area will
  42.            receive the outbounds, and vice-versa.  If the file has been seen
  43.            in BOTH areas, the inbound will be failed (renamed to *.BAD).
  44.  
  45.                 The Seenby's for BOTH areas will appear in all the generated
  46.            TICs.   If the same node is listed in both primary and  secondary
  47.            areas, the file will go to that node in the primary area only.
  48.  
  49.                 The  code is not re-entrant.   If the secondary area has its
  50.            own secondary area, a file sent in the primary area will not echo
  51.            all the way down to the 3rd area.  This prevents circular defini-
  52.            tions.
  53.  
  54.                 So what is it good for?  Several things that I can think of,
  55.            and probably a few more I haven't.   In the  SDS,  only  selected
  56.            nodes  are  given  "*"  capability in the national echos.   Using
  57.  
  58.                                                                            1
  59.  
  60.  
  61.  
  62.                                    Betatic.doc
  63.  
  64.            secondary areas,  you could have all nodes in a region link  into
  65.            SOFTDIST  via the local echo R13DIST (or whatever you might chose
  66.            to call it).   The local nodes can all be given "*" capability to
  67.            hatch to each other within R13DIST.  The files will flow locally,
  68.            but  not  enter the national echo unless the RC hatches them into
  69.            that echo.  You might choose to use the secondary area feature to
  70.            merge two echos locally,  while maintaining individual echo feeds
  71.            for  those who want or need the distinction.   To do that,  you'd
  72.            have the same secondary area  for  2  (or  more)  primary  areas.
  73.            Another use may come into play when pre-release is a reality.
  74.  
  75.                 *  Please  note that HATCH now asks for "release in how many
  76.            days?"  That is there for pre-release,  and  is  still  disabled.
  77.            (That  code  is  partially there in HATCH,  but not yet in TICK.)
  78.            You may bypass the prompt by including the command line parameter
  79.            "/R0", to tell HATCH to release it in "0" days, (ie - NOW).
  80.  
  81.                 * Defined a new Files.bbs specification.   %8 will print the
  82.            name  of  the PRIMARY area (that the file was received in) to the
  83.            Files.bbs
  84.  
  85.                 * Fixed the Doc file for the next release,  to  correct  the
  86.            keyword LINEFMT to the proper form, LISTFMT.
  87.  
  88.                 ~~~~~~~~~~~~~~~~~~~~
  89.  
  90.                 Tick 1.32 -
  91.  
  92.                 *  Hopefully  have closed a hole in the COPY routine where a
  93.            file could have been copied to a full disk  and  error  not  have
  94.            been  reported.    I  wonder  if this was the cause for occasions
  95.            where TIC's have been sent without the files?
  96.  
  97.                 * Version 1.31 of HATCH can cause some DUPs if both  primary
  98.            and  secondary areas are active and have a duplicated node listed
  99.            in both.  This version should fix that.
  100.  
  101.                 * Have added support for zones 1 - 32767.   This involved  a
  102.            lot of changes, so look for any flaky operations.
  103.  
  104.                 *  If  you  receive a pre-release file,  the planned release
  105.            date should be logged.
  106.  
  107.                 * Tick now partially implements pre-release!!!    Here's how
  108.            it  works:  Within an AREA block,  those nodes that may receive a
  109.            pre-release file before the release date should have a  "P"  flag
  110.            in  the  flag  field.    When  you  HATCH a file,  the prompt for
  111.            "Release in how many days?" is now active.   If  you  just  press
  112.            <enter>,  the  file is a normal file and is not delayed.   If you
  113.            have a file that you want to send as  a  pre-release,  place  the
  114.            file  into  the  QDIR  directory.     (QDIR  should  NEVER  be  a
  115.  
  116.                                                                            2
  117.  
  118.  
  119.  
  120.                                    Betatic.doc
  121.  
  122.            downloadable directory).   When the prompt for release days comes
  123.            up, answer with the number of days to delay.  (You may bypass the
  124.            prompt  by  using  the /Rx command line option,  where "x" is the
  125.            number of days to delay.   /R2 delays 2 days,  /R0  is  a  normal
  126.            release.
  127.  
  128.                 If  you  have specified a pre-release file,  then only those
  129.            nodes that have a "P" flag will get the file immediately.  Please
  130.            note that only nodes that are also running TICK  1.32  or  higher
  131.            should be given "P" status.   Those nodes will have TIC's and at-
  132.            taches created.   The TIC's will have the seenbys for  all  nodes
  133.            that will eventually receive the file.   In addition,  there will
  134.            be a "*.TOK" file also created in the HOLD directory.   That file
  135.            resembles a TIC closely, but has the seenby's for the pre-release
  136.            nodes only.
  137.  
  138.                 Each  time  you run TICK 1.32+,  the program will first scan
  139.            the HOLD directory for TOK files.   If it finds any,  it examines
  140.            them  to  see  if  the associated pre-release file is "ripe" yet.
  141.            When it is,  the file is moved to the destination  (downloadable)
  142.            directory, the FILES.BBS is updated, and new attaches are created
  143.            to those nodes that do not have the "P" flag.
  144.  
  145.                 THIS IS ONLY PARTIALLY IMPLEMENTED YET ...  What I will need
  146.            to do is to provide for the case where the file is "ripe" but all
  147.            the "P" flagged nodes have not yet received the file.    In  that
  148.            instance, the existing file attaches will become invalid when the
  149.            file  is moved.   I need to write code that will look for any un-
  150.            delivered attaches for that file,  and alter the FLO  or  MSG  to
  151.            point to the proper place.   Right now that hasn't been coded, so
  152.            if all "P" nodes have not had their files  delivered  before  the
  153.